DNS: El punto ciego de PCI DSS

Si creías que, implementando todos los controles de PCI DSS, ibas a ser invulnerable frente a ciberataques, puede que sea necesario que revises tu estrategia. Hay ciertas áreas técnicas que no están cubiertas por ese estándar y que deben revisarse en detalle. Una de ellas (y quizá la más importante): la infraestructura de resolución de nombres (DNS).

El estándar de seguridad de datos de la industria de tarjetas de pago (Payment Card Industry Data Security Standard – PCI DSS) define una serie de controles físicos, lógicos y administrativos para la protección de los datos de tarjetas de pago, con especial énfasis en el Número de Cuenta Primario (Primary Account Number – PAN).

En términos técnicos, PCI DSS incluye referencias explícitas a controles de seguridad como cortafuegos (firewalls), firewalls de aplicación web (Web Application Firewalls – WAF), antimalware, monitorización de la integridad de ficheros (File Integrity Monitoring – FIM), sistemas de detección y prevención de intrusiones (IDS/IPS), servicios de sincronización de tiempo (NTP), registro de eventos (logs), uso de versiones seguras de protocolos (como TLS, por ejemplo), etc. No obstante, no se incluyen controles específicos para uno de los componentes críticos de una arquitectura de red: el sistema de nombres de dominio (Domain Name System – DNS). Y es precisamente en el servicio de DNS donde puede encontrarse un “punto ciego” en el cumplimiento del estándar.

Introducción al servicio de DNS

Para entrar en contexto, el DNS es una base de datos distribuida y jerárquica que utiliza el modelo cliente-servidor y permite asociar un nombre de dominio (conocido como Fully Qualified Domain Name – FQDN) y otros datos asociados (conocidos como “registros”) con una dirección IP. La descripción técnica de los conceptos, criterios de implementación y especificación del sistema de resolución de nombres se encuentra en las RFC1034 y RFC1035.

En términos generales, existen 5 elementos principales dentro de un sistema de resolución de nombres:

• Cliente: Componente dentro de una máquina cliente que realiza solicitudes de resolución de nombres para su funcionamiento (navegadores, clientes de correo electrónico, etc.).
• DNS resolver (también conocido como “recursor” o “iterator”): Servidor encargado de recibir las peticiones de clientes para resolución de nombres. Emplea almacenamiento temporal de registros ya resueltos (caching) para optimizar los tiempos de respuesta.
• Root nameserver: Servidor encargado de proporcionar el nombre y la dirección IP del servidor autorizado de la zona de nivel más alto del dominio buscado. Actualmente existen 13 servidores de este tipo en el mundo.
• TLD (Top Level Domain) nameserver: Servidor que mantiene la información de todos los nombres de dominio que comparten una extensión de dominio común, como .com o .net. Existen varios tipos de servidores TLD, entre ellos los genéricos o gTLD (.com, .net, .edu, .org y .gov) y de país o ccTLD (.uk, .co, .jp, .es, etc.). La lista completa se puede consultar aquí.
• Authoritative nameserver: Servidor que contiene la información específica del dominio que gestiona (por ejemplo yahoo.com) y retorna la dirección IP del nombre de host especificado al DNS resolver que realizó la petición inicial.

Ejemplo del proceso de resolución de nombres

Al igual que muchos otros servicios que hicieron parte de los orígenes de internet, el DNS se desarrolló con el fin de ser operativo y escalable, pero la seguridad no fue parte de estos criterios iniciales: no había autenticación, la integridad de las respuestas no se validaba y los datos se transmitían en texto claro, deficiencias que empezaron a ser explotadas por atacantes a través de las siguientes técnicas:

• DNS spoofing / cache poisoning: En este ataque se introducen datos de DNS falsificados en la caché del DNS resolver, lo que hace que el resolver devuelva una dirección incorrecta para un dominio, desviando el tráfico a una máquina maliciosa o cualquier otro lugar que el atacante desee, con el fin de distribuir malware o recolectar datos de inicio de sesión.
• DNS Tunneling: Esta técnica permite el encapsulamiento de otros protocolos (como SSH o HTTP) en peticiones de DNS con el fin de evitar las restricciones a nivel de filtrado de paquetes, empleado para exfiltración de datos o para comunicación con servidores de mando y control (Command and Control – C&C).
• DNS hijacking: Mediante esta técnica el atacante redirige las consultas a un servidor de nombre de dominio diferente empleando malware o modificando el servidor DNS.
• Ataques de reflexión/amplificación y denegación de servicio (DoS/DDoS): En estos ataques se aprovecha la infraestructura de resolución de nombres para generar tráfico malicioso dirigido a objetivos específicos o para saturar el servicio. Algunos de estos ataques más conocidos dentro de esta categoría son NXDOMAIN, Phantom, Random subdomain, domain lock-up, botnet-based CPE, etc.

DNS y su relación con PCI DSS

Tal y como se indicaba anteriormente, el estándar PCI DSS no incluye ninguna referencia explícita al uso de controles de seguridad en la infraestructura de resolución de nombres, por lo que durante una implementación o una evaluación formal de cumplimiento pueden surgir las siguientes preguntas que pueden afectar la seguridad del entorno:

• ¿Se puede considerar el protocolo DNS y su puerto estándar (53/UDP) como “seguros”?
• ¿Es necesario implementar consideraciones de seguridad adicionales en una infraestructura tradicional de resolución de nombres?
• ¿Se requiere la designación de un servidor específico de resolución de nombres dentro de una red que procesa, almacena y/o transmite datos de tarjetas de pago?
• ¿Cómo debe realizarse la conexión entre un cliente y un servidor de DNS para resolver nombres en un entorno alineado con PCI DSS?
• ¿Qué criterio se debe emplear al elegir un servidor de resolución de nombres autoritativo?
• ¿Son confiables los servidores root y TLD que se encuentran en la parte superior de la jerarquía de DNS?
• ¿Los proveedores de servicios de registro de nombres deberían estar listados como proveedores de servicio de PCI DSS?

Actualmente, muchas de estas preguntas no tienen una respuesta formal, por lo que es bastante probable que la gran mayoría de los entornos que cumplen con PCI DSS tengan implementados controles mínimos o insuficientes para proteger su infraestructura de resolución de nombres de dominio frente a ataques.

En ese sentido, a continuación, se enumera una serie de recomendaciones para proteger los servicios de DNS del entorno de tarjetas de pago, complementando los requisitos básicos de PCI DSS:

Consideraciones para el registro de dominios vinculados a entornos PCI DSS

Otro de los grandes problemas no abordados por el estándar PCI DSS es la gestión de la seguridad de los registros de dominio vinculados a entornos PCI DSS, registrados en proveedores externos de registro de nombres, especialmente en servicios de comercio electrónico.

Como se ha descrito anteriormente, el DNS permite asociar una dirección IP a un nombre de dominio (FQDN). Cuando un usuario (un individuo o una organización) quiere registrar un nombre de dominio bajo un TLD específico, debe contactar a una entidad autorizada denominada “registrador” (registrar). Este registrador recibe la petición de registro del usuario, valida que el dominio esté disponible y, si lo está, procede a adicionar el nuevo nombre a su base de datos de registros DNS. A partir de ese momento, cualquier cambio que se requiera efectuar en el registro (renovación, transferencia o incluso edición de registros DNS y de zonas , si estas tareas han sido delegadas en el registrador) deberá realizarse mediante las interfaces provistas por este proveedor.

Si se registra un nombre de dominio que apunta a la dirección IP de un activo dentro de un entorno de PCI DSS, el registrador se convierte automáticamente en un elemento crítico de la infraestructura de la organización, ya que la responsabilidad de la operación y la administración de dicho nombre recae en esta entidad. Si un atacante compromete la red del registrador o accede de forma no autorizada a la interfaz de administración del dominio, el tráfico puede ser redirigido a servidores maliciosos sin que el usuario final se percate del cambio.

De acuerdo con el glosario del PCI SSC, un proveedor de servicios se define como “una entidad comercial que no es una marca de pago, directamente involucrada en el procesamiento, almacenamiento o transmisión de los datos del titular de la tarjeta en nombre de otra entidad. Esto también incluye a las empresas que prestan servicios que controlan o podrían afectar a la seguridad de los datos de los titulares de las tarjetas. Entre los ejemplos figuran los proveedores de servicios administrados que ofrecen cortafuegos administrados, IDS y otros servicios, así como los proveedores de hospedaje y otras entidades”.

Generalmente, una entidad registradora de dominios no se considera entre los proveedores de servicios que afectan a un entorno PCI DSS – a pesar de que sus servicios pueden afectar la seguridad de los datos de los titulares de tarjetas – por lo que no existe ninguna obligación por parte de estas entidades de cumplir con el estándar ni de agregar controles de seguridad adicionales para prevenir los riesgos asociados con la gestión de dominios.

En ese sentido, se recomienda seguir estas recomendaciones:

• Usar una entidad registradora de dominios confiable.
• Minimizar la información expuesta en la base de datos de Whois (información de los titulares de dominio) mediante servicios de registro privado.
• Si está disponible, activar la autenticación multifactor (MFA) en la interfaz de administración del dominio provista por la entidad registradora para minimizar accesos no autorizados.
• Gestionar los diferentes roles y permisos de los usuarios que pueden acceder a las interfaces de administración del DNS.
• Activar el bloqueo de cambios de DNS (DNS change locking), que añade controles adicionales al realizar cambios en los nombres de dominio registrados. Por ejemplo, un empleado de la empresa de registro de dominios puede solicitar autorización por escrito o telefónica a una persona autorizada de la empresa para realizar cambios en el DNS, solicitar un número de identificación personal (PIN), un código OTP, etc.
• Restringir el acceso a las interfaces de administración del dominio únicamente a direcciones IP autorizadas, ubicaciones físicas o dispositivos específicos.
• Activar las notificaciones (por correo electrónico, SMS, etc.) cuando se realicen cambios en el DNS.
• Configurar la renovación automática, para prevenir que un usuario malintencionado pueda adquirir el dominio cuando expire y redirigir el tráfico hacia servidores bajo su control.
• Monitorizar periódicamente los registros de DNS (sobre todo los CNAME) para detectar problemas de inactividad u obsolescencia que puedan dar lugar a que un usuario malicioso se haga con el control de subdominios (subdomain takeover).

Conclusión

“Una cadena es tan fuerte como el más débil de sus eslabones”. Esta frase la hemos escuchado múltiples veces aplicada al ámbito de la ciberseguridad y aún no ha perdido vigencia.

Un entorno que procesa, almacena y/o transmite datos de tarjetas de pago debe cumplir con los controles del estándar PCI DSS, que añade una capa de seguridad adicional para proteger dichos datos. No obstante, uno de los componentes de estos entornos que generalmente no se identifica ni se protege adecuadamente es el servicio de resolución de nombres (DNS). Debido a ello, la organización puede tener un “punto ciego” en su estrategia de seguridad, por lo que es indispensable implementar acciones preventivas y correctivas para que esto no se convierta en un vector de riesgo.

El uso de una arquitectura segura, la implementación de funcionalidades adicionales de seguridad y la protección de los registros de DNS expuestos en internet, así como el uso de servicios de DNS provistos por entidades confiables hacen parte de esta estrategia de defensa de este “eslabón débil”. Todas estas recomendaciones deberían integrarse como parte complementaria de los controles de PCI DSS en las organizaciones que deben cumplir con este estándar.

Dan J. Bernstein (DJB) anunció una serie de vulnerabilidades en el sistema DNS en 1999 y nadie lo escuchó. Dan Kaminsky encontró una vulnerabilidad grave en el sistema de DNS en 2008 y salvó Internet. No cometamos los mismos errores nuevamente…